User interface selection based on user context

ABSTRACT

Technologies are generally described to provide alternate user interfaces based on user context. In some examples, a user interface system may measure a user characteristic associated with a particular user interface type. The user interface system may then determine whether the measured user characteristic is suitable for use as a user interface input, for example by comparison with a baseline user characteristic. Upon determination that the measured user characteristic is suitable, the user interface system ma use the measured user characteristic for user interface purposes. On the other hand, upon determination that the measured user characteristic is not suitable, the user interface system may use a different user interface type to attempt to receive user inputs.

BACKGROUND

Unless otherwise indicated herein, the materials described in thissection are not prior art to the claims in this application and are notadmitted to be prior art by inclusion in this section.

A human-computer interface or user interface (UI) may allow a user tointeract with an electronic computer. In general, user interfaceimplementations may be based on converting some natural human actioninto computer input. For example, a keyboard, a mouse, a stylus, or atouchscreen may be used to convert user hand movements into computerinput. A microphone may be used to convert user speech into computerinput, and a camera may be used to convert user eye or body movementsinto computer input.

SUMMARY

The present disclosure generally describes techniques to select userinterfaces based on user context.

According to some examples, a method is provided to activate alternativeuser interfaces based on user context. The method may include measuringa user characteristic using a sensor, determining a difference betweenthe measured user characteristic and a baseline characteristic,generating a user interface conclusion based on the determineddifference, and activating a first user interface or a second userinterface based on the user interface conclusion.

According to other examples, a user interface system is provided. Theuser interface system may include a sensor configured to measure a usercharacteristic, a first user interface configured to receive user inputof a first type, a second user interface configured to receive userinput of a second type, and a controller coupled to the sensor, thefirst user interface, and the second user interface. The controller maybe configured to receive a user characteristic measurement from thesensor, determine a difference between the user characteristicmeasurement and a baseline characteristic, and use the first userinterface or the second user interface to receive user input based onthe determined difference.

According to further examples, a user interface selection system isprovided. The user interface selection system may include a memoryconfigured to store user characteristic baseline data, a user contextanalysis module coupled to the memory, and a user interface selectionmodule coupled to the user context analysis module. The user contextanalysis module may be configured to receive a user characteristicmeasurement measured by a sensor, determine a difference between thefirst user characteristic measurement and the baseline data, andgenerate a user interface conclusion based on the difference. The userinterface selection module may he configured to receive the userinterface conclusion, and in response to a determination that the userinterface conclusion is abnormal, ignore a first user input receivedfrom a first user interface and respond to a second user input receivedfrom a second user interface.

The foregoing summary is illustrative only and is not intended to be inany way limiting. In addition to the illustrative aspects, embodiments,and features described above, further aspects, embodiments, and featureswill become apparent by reference to the drawings and the followingdetailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features of this disclosure will become morefully apparent from the following description and appended claims, takenin conjunction with the accompanying drawings. Understanding that thesedrawings depict only several embodiments in accordance with thedisclosure and are, therefore, not to be considered limiting of itsscope, the disclosure will be described with additional specificity anddetail through use of the accompanying drawings, in which;

FIG. 1 illustrates how user context may affect the available userinterfaces;

FIG. 2 illustrates how user context may be used to guide the selectionof appropriate user interfaces;

FIG. 3 illustrates an example system where sensed user characteristicsmay guide the selection of an appropriate interface to present to auser;

FIG. 4 illustrates a general purpose computing device, which may be usedto provide user interface selection based on user context;

FIG. 5 is a flow diagram illustrating an example method to select userinterfaces based on user context that may be performed by a computingdevice such as the computing device in FIG. 4; and

FIG. 6 illustrates a block diagram of an example computer programproduct,

all arranged in accordance with at least some embodiments describedherein.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented herein. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe Figures, can be arranged, substituted, combined, separated, anddesigned in a wide variety of different configurations, all of which areexplicitly contemplated herein.

This disclosure is generally drawn, inter alia to methods, apparatus,systems, devices, and/or computer program products related to selectionof user interfaces based on user context.

Briefly stated, technologies are generally described to providealternate user interfaces based on user context. In some examples, auser interface system may measure a user characteristic or contextassociated with a particular user interface type. For example,availability of user hands may be determined based on weightdistribution or gait measure through a foot or plantar sensor. The userinterface system may then determine whether the measured usercharacteristic is suitable for use as a user interface input, forexample by comparison with a baseline user characteristic. Upondetermination that the measured user characteristic is suitable, theuser interface system may use the measured user characteristic for userinterface purposes. On the other hand, upon determination that themeasured user characteristic is not suitable, the user interface systemmay select a different user interface type to attempt to receive userinputs.

FIG. 1 illustrates how user context may affect the available userinterfaces, arranged in accordance with at least some embodimentsdescribed herein.

As described above, UI implementations may be based on converting somenatural human or animal action into computer input. For example,different types of UIs may convert human hand movements, human speech,human eye movements, and/or human body movements or gestures intoinputs. Although many different types of human actions may be used asthe basis for a UI, hand-based UIs may be preferred in most cases. Suchinterfaces may include keyboards or keypads, mice or other discretepointing devices, touchscreens, and gesture-sensing interfaces.

In some situations, a user may be temporarily unable to use a specificor particular UI type. For example, a first diagram 100 depicts a user102 carrying an object that wishes to open a door 110. The door 110 maybe equipped with an electronic entry system 112 configured with ahand-based UI. However, the user 102 may be unable to conveniently usethe hand-based UI because of the carried item. Accordingly, the user 102may need to drop the item or place the item elsewhere in order tooperate the entry system 112.

A second diagram 130 depicts another situation, in which a user 132 maybe temporarily unable to use a particular UI type. The user 132,carrying an object, may wish to open a storage compartment 140 of avehicle. The compartment 140, similar to the door 110, may be equippedwith an electronic opening mechanism configured to respond to ahand-based UI. For example, the compartment 140 may open when a userpresses a button on the compartment 140, or when a user manuallyactuates a remote controller. However, similar to the user 102, the user132 may be unable to conveniently open the compartment 140 because ofthe carried object.

A third diagram 160 depicts yet another situation, in which a user 162may be temporarily unable to use a particular UI type. The user 162 maycarry a portable electronic device 170, such as a smartphone, in apocket, purse, or other container. While the user 162 is carrying anobject, the device 170 may notify the user 162 of an event, such as anincoming call or a calendar appointment, using an audible or tactilealert. In this situation, the user 162, similar to the users 102 and132, may be unable to conveniently attend to the device 170 because ofthe carried object.

FIG. 2 illustrates how user context may be used to guide the selectionof appropriate user interfaces, arranged in accordance with at leastsome embodiments described herein.

In some embodiments, a UI system may be able to determine that a user istemporarily unable to use a preferred UI type, and may instead respondto user inputs through an alternate UI type. As depicted in a firstdiagram 200, which is similar to the first diagram 100, a user 202carrying an object may wish to open a door 210. The door 210 may beequipped with an electronic entry system 212 configured with ahand-based UI. Differently from the first diagram 100, the user 202 maybe able to use an alternate UI 204, and the electronic entry system 212may also be configured to respond to the alternate UI 204. For example,the alternate UI 204 may include a smart shoe that implements foot orplantar sensors and may be configured to communicate with the electronicentry system 212. Because the user 202 may be unable to use thehand-based UI of the electronic entry system 212 while carrying theobject, the user 202 may instead use the alternate UI 204 to operate theelectronic entry system 212, thereby causing the door 210 to open.

A second diagram 230 depicts another situation, in which a user 232carrying an object may be attempting to open a storage compartment 240of a vehicle. The user 232, similar to the user 202, may also use analternate UI 234, such as a smart shoe implementing foot or plantarsensors as described above. The storage compartment 240 may be equippedwith an electronic opening mechanism configured to respond both to ahand-based UI and to the alternate UI 234 via a sensor 242. As in thefirst diagram 200, because the user 232 may be unable to use thehand-based UI of the electronic opening mechanism while carrying theobject, the user may instead use the alternate UI 234 to open thestorage compartment 240.

A third diagram 260 depicts a situation, in which a user 262 receives anotification from a carried electronic device 270 while carrying anobject. Similar to the situations depicted in the first diagram 200 andthe second diagram 230, the electronic device 270 may be configured torespond to both a hand-based UI and to an alternate UI 264. Accordingly,instead of using a hand-based UI to attend to the device 270 the user262 may be able to use an alternate UI 264, which may be voice input ora smart shoe as discussed above, for example, to control the device 270.

FIG. 3 illustrates an example system where sensed user characteristicsmay guide the selection of an appropriate interface to present to auser, arranged in accordance with at least some embodiments describedherein.

As shown in FIG. 3, a UI system 300 may include a controller 310 coupledto a plantar sensor 302 and one or more other sensors 304. Thecontroller 310 may also be coupled to other input output devices, suchas a touch screen 326 and a microphone 328.

As described above, a UI system according to embodiments may be able torespond to inputs from multiple UI types. For example, the UI system 300may be able to respond to an input from a hand-based UI such as thetouch screen 326 and/or an input from a foot-based UI such as theplantar sensor 302. The UI system 300 may further be configured to (a)determine the appropriate type of UI input to respond to, and (b) todistinguish between user-intended inputs of a particular UI type fromunintended inputs of the same UI type. For example, if the UI system 300receives input from both the plantar sensor 302 and the microphone 328,the UI system 300 may determine whether it should respond to the inputfrom the plantar sensor 302 or whether it should instead respond to theinput from the microphone 328. As another example, if the UI systemdetects input from the plantar sensor 302, the UI system 300 maydetermine whether the input corresponds to an intentional command fromthe user or to an ordinary foot movement, such as walking.

Accordingly, the controller 310 may include a user context analysismodule 312 configured to receive inputs from the plantar sensor 302and/or the other sensor(s) 304. The user context analysis module 312 maybe configured to determine a user context based on inputs from one ormore sensors such as the plantar sensor 302, where the user context mayindicate whether the user is able to access hand-based UI, for example.In some embodiments, the user context analysis module 312 may haveaccess to user baseline data 314 to determine the user context. The userbaseline data 314 may store prior data collected front the plantarsensor 302 and/or the other sensor(s) 304 associated with the user. Forexample, a user's wearing pattern of the plantar sensor 302 may bedetermined from prior usage, and the user baseline data 314 may includeinformation about the user's average weight (for example, in terms offoot pressure data sensed, by the plantar sensor 302), information aboutthe average weight distribution of the user on both feet (assuming thatthe plantar sensor 302 includes sensors associated with each foot),information about the user's typical gait, and other relevant historicalinformation associated with the user's feet movement. In particular, theuser baseline data 314 may represent sensor data collected when the useris not attempting to provide UI inputs. In other examples, the userbaseline data 314 may be seasonal, for example, heavier clothing worn bythe user in colder season may affect weight. The user baseline data 314may also be based on particular activity undertaken by the user. Theuser may indicate what activity the user is currently performing, or theactivity may be interred from user calendar or any of the sensorsdiscussed herein. For example, swimming may affect weight, running mayaffect gait, etc. In yet other examples, other factors that may affectthe user baseline data 314 such as weight gain or loss by the user,health problems (e.g., injured limbs, etc.) may be factored into thedetermination.

The user context analysis module 312 may then be able to use thealready-collected user baseline data 314 to determine whether datareceived from the plantar sensor 302 and/or the other sensors 304indicate that a user's hands are likely available to interact with aconventional user interface (in other words, the user is probably notcarrying a fairly large or heavy object) or unavailable to interact witha conventional user interface (in other, words, the user is probablycarrying a fairly large or heavy object). In some embodiments, the usercontext analysis module 312 may compare the received data to the userbaseline data 314. If the difference between the received data and theuser baseline data 314 is relatively low (for example, below aparticular threshold), then the user context analysis module 312 mayconclude that the user's hands are likely available. On the other hand,if the difference between the received data and the user baseline data314 is relatively large (for example, above a particular threshold),then the user context analysis module 312 may conclude that the user'shands are likely unavailable.

In one example., the user context analysis module 312 may determine thatdata received from the plantar sensor 302 indicates that the user'sweight has increased with respect to the user baseline data 314. Theuser context analysis module 312 may then conclude that the user may becarrying a relatively heavy object, and that the user's hands are likelyunavailable.

In another example, data received from the plantar sensor 302 mayindicate that the user's weight distribution has changed with respect tothe user baseline data 314. The user context analysis module 312 maythen conclude that the user may be carrying an object using one or twohands, and may be able to determine the specific hand used to carry theobject. Based on this information, the user context analysis module 312may be able to determine whether the user's hands (none, one, or both)are available.

In yet another example, data received from the plantar sensor 302 mayindicate that the user's gait has changed with respect to the userbaseline data 314. The user context analysis module 312 may thenconclude that the user may be carrying an object with a large volume,and that the user's hands are likely unavailable. In some embodiments,gait information may be used to determine whether a user is wearing abag or carrying an object with hands, which the user context analysismodule 312 may use to determine whether the user's hands are available.

In some embodiments, the user context analysis module 312 may also usedata received from the other sensors 304 to determine user context. Forexample, the other sensors 304 may include a sensor capable ofidentifying user arm or wrist movements, such as a smartwatch or asports tracker. User arm movements, similar to gait information asdescribed above, may vary based on whether objects are held in the hand.Accordingly, the user context analysis module 312 may be able to use armmovement data received from the other sensors 304 to supplement thedetermination of whether the user's hands are available.

The user context analysis module 312 may also use other data 316 todetermine user context. In some embodiments, the other data 316 mayinclude prior user context determinations and associated user reactions.For example, the user context analysis module 312 may have previouslydetermined that a user's hands were available when in fact the user'shands were unavailable, or vice-versa. These misdetection cases may beused by the user context analysis module 312, the controller 310, oranother processor as supervised data for machine learning, therebyimproving the accuracy of user context detection.

The user context conclusion determined by the user context analysismodule 312 (for example, whether the user's hands are likely availableor not) may then be sent to a UI selection module 318. The UI selectionmodule 318 may then select or activate one or more UI modules 324, eachof which may be coupled to a UI such as the plantar sensor 302, thetouch screen 326, and the microphone 328, for receiving UI inputs. Forexample, if the user context conclusion from the user context analysismodule 312 is that the user's hands are available, the UI selectionmodule 318 may select the UI module coupled to the touch screen 326 toreceive UI inputs. In some embodiments, the UI selection module 318 mayignore inputs from other UIs, such as the plantar sensor 302 and themicrophone 328, or deactivate the UI modules corresponding to those UIs.In other embodiments, a particular UI module (for example, the onecoupled to the touch screen 326) may be considered a primary UI, and theother UI modules may be considered secondary UIs. The UI selectionmodule 318 may then determine whether the user context conclusion isnormal (that is, the user can access the primary UI) or abnormal (thatis, the user cannot access the primary UI), and select and/or deactivateUIs accordingly. For example, the UI selection module 318 may activatethe primary UI if the user context conclusion is normal, and mayactivate a secondary UI if the user context conclusion is abnormal.

In further embodiments, the UI selection module 318 may useenvironmental parameters to determine the UI module to be selected. Forexample, the UI selection module 318 may use the other data 316,location data 320, and/or user preferences data 322. The other data 316may include identifiers for nearby devices that may be able to serve asalternative UIs. The location data 320 may indicate whether the currentlocation of the user is amenable to particular types of UI inputs. Theuser preferences data 322 may indicate whether the user prefers to useone type of UI (for example, speech recognition) to another type of UI(for example, hand-based UI).

FIG. 4 illustrates a general purpose computing device, which may be usedto provide user interface selection based on user context, arranged inaccordance with at least some embodiments described herein.

For example, the computing device 400 may be used to select anappropriate user interface based on user context as described herein. Inan example basic configuration 402, the computing device 400 may includeone or more processors 404 and a system memory 406. A memory bus 408 maybe used to communicate between the processor 404 and the system memory406. The basic configuration 402 is illustrated in FIG. 4 by thosecomponents within the inner dashed line.

Depending on the desired configuration, the processor 404 may be of anytype, including but not limited to a microprocessor (μP), amicrocontroller (μC), a digital signal processor (DSP), or anycombination thereof. The processor 404 may include one more levels ofcaching, such as a level cache memory 412, a processor core 414, andregisters 416. The example processor core 414 may include an arithmeticlogic unit (ALU), a floating point unit (FPU), a digital signalprocessing core (DSP Core), or any combination thereof. An examplememory controller 418 may also be used with the processor 404, or insome implementations the memory controller 418 may be an internal partof the processor 404.

Depending on the desired configuration, the system memory 406 may be ofany type including but not limited to volatile memory (such as RAM),non-volatile memory (such as ROM, flash memory, etc.) or any combinationthereof. The system memory 406 may include an operating system 420, auser interface module 422, and program data 424. The user interfacemodule 422 may include a user context analysis module 426 configured toprovide a user interface conclusion based on user context and a UIselection module 428 configured to select an appropriate UI based on theuser interface conclusion as described herein. The program data 424 mayinclude, among other data, user baseline data 430 or the like, asdescribed herein.

The computing device 400 may have additional features or functionality,and additional interfaces to facilitate communications between the basicconfiguration 402 and any desired devices and interfaces. For example, abus/interface controller 430 may be used to facilitate communicationsbetween the basic configuration 402 and one or more data storage devices432 via a storage interface bus 434. The data storage devices 432 may beone or more removable storage devices 436, one or more non-removablestorage devices 438, or a combination thereof. Examples of the removablestorage and the non-removable storage devices include magnetic diskdevices such as flexible disk drives and hard-disk drives (HDD), opticaldisk drives such as compact disc (CD) drives or digital versatile disk(DVD) drives, solid state drives (SSD), and tape drives to name a few.Example computer storage media may include volatile and nonvolatile,removable and non-removable media implemented in any method ortechnology for storage of information, such as computer readableinstructions, data structures, program modules, or other data.

The system memory 406, the removable storage devices 436 and thenon-removable storage devices 438 are examples of computer storagemedia. Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD), solid state drives, or other optical storage,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, or any other medium which may be used to storethe desired information and which may be accessed by the computingdevice 400. Any such computer storage media may be part of the computingdevice 400.

The computing device 400 may also include an interface bus 440 forfacilitating communication from various interface devices (e.g., one ormore output devices 442, one or more peripheral interfaces 450, and oneor more communication devices 460) to the basic configuration 402 viathe bus; interface controller 430. Some of the example output devices442 include a graphics processing unit 444 and an audio processing unit446, which may be configured to communicate to various external devicessuch as a display or speakers via one or more A/V ports 448. One or moreexample peripheral interfaces 450 may include a serial interfacecontroller 454 or a parallel interface controller 456, which may beconfigured to communicate with external devices such as input devices(e.g., keyboard, mouse, pen, voice input device, touch input device,etc.) or other peripheral devices (e.g., printer, scanner, etc.) via oneor more I/O ports 418. An example communication device 460 includes anetwork controller 462, which may be arranged to facilitatecommunications with one or more other computing devices 466 over anetwork communication link via one or more communication ports 464. Theone or more other computing devices 466 may include servers at adatacenter, customer equipment, and comparable devices.

The network communication link may be one example of a communicationmedia. Communication media may be embodied by computer readableinstructions, data structures, program modules, or other data in amodulated data signal, such as a carrier wave or other transportmechanism, and may include any information delivery media. A “modulateddata signal” may be a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media may includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), microwave,infrared (IR) and other wireless media. The term computer readable mediaas used herein may include both storage media and communication media.

The computing device 400 may be implemented as a part of a generalpurpose or specialized server, mainframe, or similar computer thatincludes any of the above functions. The computing device 400 may alsobe implemented as a personal computer including both laptop computer andnon-laptop computer configurations.

FIG. 5 is a flow diagram illustrating an example method to select userinterfaces based on user context that may be performed by a computingdevice such as the computing device in FIG. 4, arranged in accordancewith at least some embodiments described herein.

Example methods may include one or more operations, functions or actionsas illustrated by one or more of blocks 522, 524, 526, and/or 528, andmay in some embodiments be performed by a computing device such as thecomputing device 510 in FIG. 5. The operations described in the blocks522-528 may also be stored as computer-executable instructions in acomputer-readable medium such as a computer-readable medium 520 of acomputing device 510.

An example process to select user interfaces based on user context maybegin with block 522, “MEASURE ONE OR MORE USER CHARACTERISTICS”, wherea user context analysis module such as the user context analysis module312 may measure one or more user characteristics, such as user weight,user weight distribution, user gait, or any relevant usercharacteristic. In some embodiments, the user context analysis modulemay base the user characteristic measurement on data from one or moresensors, such as the plantar sensor 302.

Block 522 may be followed by block 524, “COMPARE THE MEASURED USERCHARACTERISTICS WITH BASELINE CHARACTERISTICS”, where the user contextanalysis module may compare the user characteristics measured in block522 with baseline user characteristics, such as the user baseline data314, as described above.

Block 524 may be followed by block 526, “GENERATE A USER INTERFACECONCLUSION BASED ON THE COMPARISON”, where the user context analysismodule may generate a user interface conclusion based on whether thereceived data differs substantially from the baseline data (e.g., abovea particular threshold), as described above. For example, the usercontext analysis module may generate a user interface conclusion that aparticular UI type is available to a user if the received data does notdiffer significantly from the baseline data, and may generate a userinterface conclusion that the UI type is not available to the user ifthe received data differs significantly from the baseline data.

Block 526 may be followed by block 528, “SELECT USER INTERFACE(S) TOACTIVATE OR USE AND/OR SELECT USER INTERFACE(S) TO DEACTIVATE OR IGNOREBASED ON THE USER INTERFACE CONCLUSION”, where a selection module suchas the UI selection module 318 may select UIs to use or ignore based onthe user interface conclusion. For example, the UI selection module mayselect a primary UI to use if the user interface conclusion indicatesthat the primary UI type is available to a user, and may select asecondary UI to use if the user interface conclusion indicates that theprimary UI type is not available to a user, as described above. In someembodiments, the UI selection module may use other information, such aslocation data, the identity of nearby devices, and/or user preferencedata to select the UIs to use or ignore.

FIG. 6 illustrates a block diagram of an example computer programproduct, arranged in accordance with at least some embodiments describedherein.

In some examples, as shown in FIG. 6, a computer program product 600 mayinclude a signal bearing medium 602 that may also include one or moremachine readable instructions 604 that, when executed by, for example, aprocessor may provide the functionality described herein. Thus, forexample, referring to the processor 404 in FIG. 4, the user interfacemodule 422 may undertake one or more of the tasks shown in FIG. 6 inresponse to the instructions 604 conveyed to the processor 404 by themedium 602 to perform actions associated with selecting user interfacesbased on user context as described herein. Some of those instructionsmay include, for example, instructions to measure one or more usercharacteristics, compare the measured user characteristics with baselinecharacteristics, generate a user interface conclusion based on thecomparison, and/or select user interface(s) to activate or use and/orselect user interface(s) to deactivate or ignore based on the userinterface conclusion, according to some embodiments described herein.

In some implementations, the signal bearing media 602 depicted in FIG. 6may encompass computer-readable media 606, such as, but not limited to,a hard disk drive, a solid state drive, a compact disc (CD), a digitalversatile disk (DVD), a digital tape, memory, etc. In someimplementations, the signal bearing media 602 may encompass recordablemedia 608, such as, but not limited to, memory, read/write (R/W) CDs,R/W DVDs, etc. In some implementations, the signal bearing media 602 mayencompass communications media 610, such as, but not limited to, adigital and/or an analog communication medium (e.g., a fiber opticcable, a waveguide, a wired communications link, a wirelesscommunication link, etc.). Thus, for example, the program product 600may be conveyed to one or more modules of the processor 404 by an RFsignal bearing medium, where the signal bearing media 602 is conveyed bythe wireless communications media 600 (e.g., a wireless communicationsmedium conforming with the IEEE 802.11 standard).

According to some examples, a method is provided to activate alternativeuser interfaces based on user context. The method may include measuringa user characteristic using a sensor, determining a difference betweenthe measured user characteristic and a baseline characteristic,generating a user interface conclusion based on the determineddifference, and activating a first user interface or a second userinterface based on the user interface conclusion.

According to some embodiments, the user characteristic may be footpressure, weight distribution, and/or a gait. The first user interfacemay be a hand-based interface and the second user interface may be avoice-based interface and/or a foot-based interface. Activating thefirst user interface or the second interface may include activating thefirst user interface in response to determining that the user interfaceconclusion is normal and activating the second user interface m responseto determining that the user interface conclusion is abnormal. In someembodiments, generating the user interface conclusion may includegenerating the user interface conclusion based on the determineddifference and an arm sensor measurement. The method may further includecollecting the baseline characteristic prior to measuring the usercharacteristic. Generating the user interface conclusion may furtherinclude generating the user interface conclusion based on the determineddifference and a location, a user preference, and/or a nearby deviceidentifier.

According to other examples, a user interface system is provided. Theuser interface system may include a sensor configured to measure a usercharacteristic, a first user interface configured to receive user inputof a first type, a second user interface configured to receive userinput of a second type, and a controller coupled to the sensor, thefirst user interface, and the second user interface. The controller maybe configured to receive a user characteristic measurement from thesensor, determine a difference between the user characteristicmeasurement and a baseline characteristic, and use the first userinterface or the second user interface to receive user input based onthe determined difference.

According to some embodiments, the sensor may be a plantar sensor andthe user characteristic may be foot pressure, weight distribution,and/or a gait. The first user interface may be a hand-based interfaceand the second user interface may be a voice-based interface and/or afoot-based interface. The controller may be configured to use the firstuser interface to receive user input in response to a determination thatthe determined difference is less than a characteristic threshold anduse the second user interface to receive user input in response to adetermination that the determined difference is greater than thecharacteristic threshold.

According to other embodiments, the user interface system may furtherinclude an arm sensor configured to provide an arm measurement, and thecontroller may be configured to determine the difference based on thearm measurement. The controller may be further configured to determinethe difference based on one or more environmental parameters, where theenvironmental parameters may include a location, a user preference,and/or a nearby device identifier. The controller may, be furtherconfigured to determine the baseline characteristic prior to receivingthe user characteristic measurement.

According to further examples, a user interface selection system isprovided. The user interface selection system may include a memoryconfigured to store user characteristic baseline data, a user contextanalysis module coupled to the memory, and a user interface selectionmodule coupled to the user context analysis module. The user contextanalysis module may be configured to receive a user characteristicmeasurement measured by a sensor, determine a difference between thefirst user characteristic measurement and the baseline data, andgenerate a user interface conclusion based on the difference. The userinterface selection module may be configured to receive the userinterface conclusion, and in response to a determination that the userinterface conclusion is abnormal, ignore a first user input receivedfrom a first user interface and respond to a second user input receivedfrom a second user interface.

According to some embodiments, the user characteristic measurement maybe associated with foot pressure, weight distribution, and/or a gait.The first user interface may be a hand-based interface and the seconduser interface may be a voice-based interface and/or a foot-basedinterface. The user interface selection module may be further configuredto respond to the first user input received from the first userinterface in response to a determination that the user interfaceconclusion is normal. The user context analysis module may be furtherconfigured to generate the user interface conclusion based on an armsensor measurement, a location, a user preference, and/or a nearbydevice identifier.

There is little distinction left between hardware and softwareimplementations of aspects of systems; the use of hardware or softwareis generally (but not always, in that in certain contexts the choicebetween hardware and software may become significant) a design choicerepresenting cost vs. efficiency tradeoffs. There are various vehiclesby which processes and/or systems and/or other technologies describedherein may be effected (e.g., hardware, software, and/or firmware), andthat the preferred vehicle will vary with the context in which theprocesses and/or systems and/or other technologies are deployed. Forexample, if an implementer determines that speed and accuracy areparamount, the implementer may opt for a mainly hardware and/or firmwarevehicle; if flexibility is paramount, the implementer may opt for amainly software implementation; or, yet again alternatively, theimplementer may opt for some combination of hardware, software, and/orfirmware.

The foregoing detailed description has set forth various embodiments ofthe devices and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and; or operationwithin such block diagrams, flowcharts, or examples may be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or virtually any combination thereof. In one embodiment,several portions of the subject matter described herein may beimplemented via application specific integrated circuits (ASICs), fieldprogrammable gate arrays (FPGAs), digital signal processors (DSPs), ofother integrated formats. However, those skilled in the art willrecognize that some aspects of the embodiments disclosed herein, inwhole or in part, may be equivalently implemented in integratedcircuits, as one or more computer programs executing on one or morecomputers (e.g., as one or more programs executing on one or morecomputer systems), as one or more programs executing on one or moreprocessors (e.g., as one or more programs executing on one or moremicroprocessors), as firmware, or as virtually any combination thereof,and that designing the circuitry and/or writing the code for thesoftware and or firmware would be well within the skill of one of skillin the art in light of this disclosure.

The present disclosure is not to be limited in terms of the particularembodiments described in this application, which are intended asillustrations of various aspects. Many modifications and variations canbe made without departing from its spirit and scope, as will be apparentto those skilled in the art. Functionally equivalent methods andapparatuses within the scope of the disclosure, in addition to thoseenumerated herein, will be apparent to those skilled in the art from theforegoing descriptions. Such modifications and variations are intendedto fall within the scope of the appended claims. The present disclosureis to be limited only by the terms of the appended claims, along withthe full scope of equivalents to which such claims are entitled. It isalso to be understood that the terminology used herein is for thepurpose of describing particular embodiments only, and is not intendedto be limiting.

In addition, those skilled in the art will appreciate that themechanisms of the subject matter described herein are capable of beingdistributed as a program product in a variety of forms, and that anillustrative embodiment of the subject matter described herein appliesregardless of the particular type of signal bearing medium used toactually carry out the distribution. Examples of a signal bearing mediuminclude, but are not limited to, the following: a recordable type mediumsuch as a floppy disk, a bard disk drive, a compact disc (CD), a digitalversatile disk (DVD), a digital tape, a computer memory, a solid statedrive, etc.; and a transmission type medium such as a digital and/or ananalog communication medium (e.g., a fiber optic cable, a waveguide, awired communications link, a wireless communication link, etc.).

Those skilled in the art will recognize that it is common within the artto describe devices and/or processes in the fashion set forth herein,and thereafter use engineering practices to integrate such describeddevices and/or processes into data processing systems. That is, at leasta portion of the devices and/or processes described herein may beintegrated into a data processing system via a reasonable amount ofexperimentation. Those having skill in the art will recognize that adata processing system may include one or more of a system unit housing,a video display device, a memory such as volatile and non-volatilememory, processors such as microprocessors and digital signalprocessors, computational entities such as operating systems, drivers,graphical user interfaces, and applications programs, one or moreinteraction devices, such as a touch pad or screen, and/or controlsystems including feedback loops and control motors (e.g., feedback forsensing position and/or velocity of gantry systems; control motors tomove and/or adjust components and/or quantities).

A data processing system may be implemented utilizing any suitablecommercially available components, such as those found in data computingcommunication and/or network computing/communication systems. The hereindescribed subject matter sometimes illustrates different componentscontained within, or connected with, different other components, it isto be understood that such depicted architectures are merely exemplary,and that in fact many other architectures may be implemented whichachieve the same functionality. In a conceptual sense, any arrangementof components to achieve the same functionality is effectively“associated” such that the desired functionality is achieved. Hence, anytwo components herein combined to achieve a particular functionality maybe seen as “associated with” each other such that the desiredfunctionality is achieved, irrespective of architectures or intermediatecomponents. Likewise, any two components so associated may also beviewed as being “operably connected”, or “operably coupled”, to eachother to achieve the desired functionality, and any two componentscapable of being so associated may also be viewed as being “operablycouplable”, to each other to achieve the desired functionality. Specificexamples of operably couplable include but are not limited to physicallyconnectable and/or physically interacting components and/or wirelesslyinteractable and/or wirelessly interacting components and/or logicallyinteracting and/or logically interactable components.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” Should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to embodiments containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should be interpreted to mean “at least one”or “one or more”) the same holds true for the use of definite articlesused to introduce claim recitations. In addition, even if a specificnumber of an introduced claim recitation is explicitly recited, thoseskilled in the art will recognize that such recitation should beinterpreted to mean at least the recited number (eq., the barerecitation of “two recitations,” without other modifiers, means at leasttwo recitations, or two or more recitations).

Furthermore, in those instances where a convention analogous to “atleast one of A, B, and C, etc.” is used, in general such a constructionis intended in the sense one having skill in the art would understandthe convention (e.g., “a system having at least one of A, B, and C”would include but not be limited to systems that have A alone, B alone,C alone, A and B together, A and C together, B and C together, and/or A,B, and C together, etc.). It will be further understood by those withinthe art that virtually any disjunctive word and/or phrase presenting twoor more alternative terms, whether in the description, claims, ordrawings, should be understood to contemplate the possibilities ofincluding one of the terms, either of the terms, or both terms. Forexample, the phrase “A or B” will be understood to include thepossibilities of “A” or “B” or “A and B.”

As will be understood by one skilled in the art, for any and allpurposes, such as in terms of providing a written description, allranges disclosed herein also encompass any and all possible subrangesand combinations of subranges thereof. Any listed range can be easilyrecognized as sufficiently describing and enabling the same range beingbroken down into at least equal halves, thirds, quarters, fifths,tenths, etc. As a non-limiting example, each range discussed herein canbe readily broken down into a lower third, middle third and upper third,etc. As will also be understood by one skilled in the art all languagesuch as “up to,” “at least,” “greater than,” “less than,” and the likeinclude the number recited and refer to ranges which can be subsequentlybroken down into subranges as discussed above. Finally, as will beunderstood by one skilled in the art, a range includes each individualmember. Thus, for example, a group having 1-3 cells refers to groupshaving 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers togroups having 1, 2, 3, 4, or 5 cells, and so forth.

While various aspects and embodiments have been disclosed herein, otheraspects and embodiments will be apparent to those skilled in the art.The various aspects and embodiments disclosed herein are for purposes ofillustration and are not intended to be limiting, with the true scopeand spirit being indicated by the following claims.

What is claimed is:
 1. A method to activate alternative user interfacesbased on user context, the method comprising: measuring a usercharacteristic using a sensor; determining a difference between themeasured user characteristic and a baseline characteristic: generating auser interface conclusion based on the determined difference; andactivating one of a first user interface and a second user interfacebased on the user interface conclusion.
 2. The method of claim 1,wherein the user characteristic is at least one of foot pressure, weightdistribution, and a gait.
 3. The method of claim 1, wherein the firstuser interface is a hand-based interface and the second user interfaceis at least one of a voice-based interface and a foot-based interface.4. The method of claim 1, wherein activating one of the first userinterface and the second user interface comprises: activating the firstuser interface in response to determining that the user interfaceconclusion is normal; and activating the second user interface inresponse to determining that the user interface conclusion is abnormal.5. The method of claim 4, wherein generating the user interfaceconclusion further comprises generating the user interface conclusionbased on the determined difference and an arm sensor measurement.
 6. Themethod of claim 1, further comprising collecting the baselinecharacteristic prior to measuring the user characteristic.
 7. The methodof claim 1, wherein generating the user interface conclusion furthercomprises generating the user interface conclusion based on thedetermined difference and at least one of a location, a user preference,and a nearby device identifier.
 8. A user interface system comprising: asensor configured to measure a user characteristic; a first userinterface configured to receive user input of a first type; a seconduser interface configured to receive user input of a second type; and acontroller coupled to the sensor, the first user interface, and thesecond user interface, the controller configured to: receive a usercharacteristic measurement from the sensor; determine a differencebetween the user characteristic measurement and a baselinecharacteristic; and based on the determined difference, use one of thefirst user interface and the second user interface to receive userinput.
 9. The user interface system of claim 8, wherein: the sensor is aplantar sensor; and the user characteristic is at least one of footpressure, weight distribution, and a gait.
 10. The user interface systemof claim 8, wherein the first user interface is a hand-based interfaceand the second user interface is at least one of a voice-based interfaceand a foot-based interface.
 11. The user interface system of claim 8,wherein the controller is further configured to use the first userinterface to receive user input in response to a determination that thedetermined difference is less than a characteristic threshold; and usethe second user interlace to receive user input in response to adetermination that the determined difference is greater than thecharacteristic threshold.
 12. The user interface system of claim 8,further comprising an arm sensor configured to provide an armmeasurement, and wherein the controller is further configured todetermine the difference based on the arm measurement.
 13. The userinterface system of claim 8, wherein the controller is furtherconfigured to determine the difference based on at least oneenvironmental parameter.
 14. The user interface system of claim 13,wherein the at least one environmental parameter includes at least oneof a location, a user preference, and a nearby device identifier. 15.The user interface system of claim 8, wherein the controller is furtherconfigured to determine the baseline characteristic prior to receivingthe user characteristic measurement.
 16. A user interface selectionsystem comprising: a memory configured to store user characteristicbaseline data; and a user context analysis module coupled to the memoryand configured to: receive a user characteristic measurement, the usercharacteristic measurement measured by a sensor; determine a differencebetween the user characteristic measurement and the baseline data; andgenerate a user interface conclusion based on the difference; and a userinterface selection module coupled to the user context analysis moduleand configured to: receive the user interface conclusion; and inresponse to a determination that the user interface conclusion isabnormal, at least one of: ignore a first user input received from afirst user interface; and respond to a second user input received from asecond user interface.
 17. The user interface selection system of claim16, wherein the user characteristic measurement is associated with atleast one of foot pressure, weight distribution, and a gait.
 18. Theuser interface selection system of claim 16, wherein the first userinterface is a hand-based interface and the second user interface is atleast one of a voice-based interface and a foot-based interface.
 19. Theuser interface selection system of claim 16, wherein the user interfaceselection module is further configured to, in response to adetermination that the user interface conclusion is normal, respond tothe first user input received from the first user interface.
 20. Theuser interface selection system of claim 16, wherein the user contextanalysis module is further configured to generate the user interfaceconclusion based on at least one of an arm sensor measurement, alocation, a user preference, and a nearby device identifier.